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■VEHICULAR TELEMETRY* 
REFERENCE TO CO-PENDING APPLICATIONS 

The subject matter of both provisional application serial number 
60/056.388 filed August 26, 1997 and utility patent application serial number 
09/140.759 filed August 26, 1998 (both entitled SYSTEM AND METHOD FOR 
PROVIDING MOBILE AUTOMOTIVE TELEMETRY) is incorporated herein by 
reference. The subject matter of PCT Application serial number PCT/CA98/00986 filed 
October 23. 1998 entitled TELECOMMUNICATIONS SYSTEM and designating the 
United States is also incorporated herein by reference. The subject matter of provisional 
application serial number 60/139.573 filed June 17, 1999 and entitled VEHICULAR 
TELEMETRY is also incorporated herein by reference. The subject matter of U.S. 
provisional application serial number 60/148.270, filed on August 11, 1999 and entitled 
VEHICULAR COMPUTING DEVICE is also incorporated herein by reference. The 
subject matter of U.S. provisional application serial number 60/187,022 March 6, 2000 is 
also incorporated herein by reference. 

BACKGROUND OF THE INVENTION 

FIELD OF THE INVENTION 

The present invention relates to data communications systems and more 
particularly to the field of vehicular telemetry using RF packet networks in conjunction 
with internet or similar protocols. 

DESCRIPTION OF THE RELATED ART 

Hereinafter numerical reference is made to materials listed in Appendix A 
at the end of the disclosure. 
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Conventionally, vehicles have been known to exchange data with a 
diagnostic computer system (such as in a repair garage) over a hardwired or infrared data 
link, or a regulatory computer system (such as an electronic toll highway) by a data link 
using a low power transponder. 

More sophisticated vehicular telemetry for commercial fleets has been 
made possible in the last several years through satellite RF packet networks. In these 
vehicular telemetry systems, vehicle sensor data can be transported over wireless data 
links to a computer that is programmed to monitor and record automotive phenomena and 
to support database systems for vehicular maintenance, without the need for the vehicle to 
be in a particular service bay for example. However, these systems are relatively 
expensive to operate. 

A considerable amount of research is being dedicated to developing 
feasible Intelligent Vehicle Highway Systems (TVHS) which are computer-assisted 
methods to manage highway infrastructures, synchronize traffic lights, measure traffic 
flow, to alert drivers to ongoing traffic conditions through electronic billboards and other 
innovations aimed at improving the quality and efficiency of road transportation systems 
for vehicles. 

The California Air Resources Board (CARB) has been a leader in 
establishing standards for monitoring vehicle emissions. A recent CARB initiative, 
known as OBD-HI, is the third generation of on-board diagnostic requirement, calling for 
an emissions regulatory agency to retrieve, remotely, diagnostic data from vehicles, 
thereby avoiding the need for a visit to a clean air inspection station. In one pilot 
program, a low-power transponder was used on each vehicle, capable of transferring data 
between the vehicle and a roadside receiver. Of course, in order for the OBD-III 
proposal to proceed, each vehicle must have a system capable of collecting and 
dispatching the requested data through the transponder. CARB is actively reviewing 
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currently available technologies and is surveying the telecommunications industry to see 
what future equipment is planned. The operating platforms tested thus far by CARB 
have been relatively cumbersome and have limited capability to be used for other data 
exchange needs in the future. There is interest in finding a platform that will be 
economical to operate in order to minimize the financial burden placed on the consumer 
to implement the proposal. 

Morever. it would be desirable for the chosen platform to be capable of 
doing more than just sending diagnostic information to a clean air agency. Both the 
telecom and auto industries are looking at ways to utilize the tremendous business 
opportunities of reaching urban commuters in their vehicles while they devote several 
hours each day to their commute. 

Vehicular traffic has become a major problem for urban planners. With 
land values skyrocketing and land-use issues becoming more of a concern, planners are 
looking for ways of getting more vehicles through existing commuter arteries as an 
alternative to expanding them. It is also known that the actual volume of traffic handled 
by a thoroughfare plummets when traffic becomes congested. Therefore, it would be 
desirable to have vehicles which are capable of exchanging data with themselves as a way 
to control such things as safe driving distances to avoid collisions and exchanging data 
with traffic monitoring systems to control such things as driving speeds. 

It is therefore an object of the present invention to provide a improved 
platform for vehicular telemetry. 

It is a further object of the present invention to provide an improved 
vehicular telemetry system which is relatively inexpensive, yet capable of exchanging a 
range of useful data through a data communications system between a vehicle and a fixed 
location. 

- s _ 
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It is still a further object of the present invention to provide a vehicle 
communications system in which the vehicles therein are each capable of communicating 
both through a data communications system and with themselves. 

SUMMARY OF THE INVENTION 

Briefly stated, the invention involves, in one of its aspects, a method of 
exchanging data between a mobile node and an access point on a communication 
network, comprising the steps of: 



access point; 



a) providing at least two data links between the mobile node and the 

b) measuring impedance on each data link: and 

c) transmitting said data across the data link having the lowest impedance. 



Preferably, the data links are wireless and a first of the data links is 
established on a spread spectrum radio frequency (RF) band. The data links may also 
comprise a satellite RF packet network or a terrestrial RF packet network. It is 
contemplated that other data links may become available in future as wireless data 
communications evolve. 

In another of its aspects, the present invention provides a communications 
system, composing 

a mobile communications network having a mobile node, 

a fixed communications network having an access point, 
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a pair of alternative data links, each of which joins the mobile node with 
the access point, and 

a switching unit for switching between the alternative data links to 
exchange data between the mobile node and the access point. 

In one embodiment, the mobile communications network includes a 
plurality of vehicle- mounted mobile nodes wherein at some are Internet addressable, for 
example under IPv6 protocol. Each mobile node and selected ones of the access points 
operate under the IEEE 802. 1 1 standard. In this case, the data link joins each mobile node 
with at least one access point on a spread spectrum band. At least some of the access 
points are located adjacent a roadway. 

Preferably, the system includes a measuring module for measuring 
impedance on each of the data links. In this case, the switching unit is operable to select 
the data link having the least impedance. 

In still another of its aspects, the present invention provides a 
communications network for exchanging data between a plurality of vehicles, comprising 
a computing unit onboard a corresponding vehicle, each computing unit being operable in 
a first phase to broadcast enquiry messages in a region surrounding the vehicle, a second 
phase to receive reply messages from other vehicles in the region, and a third phase to 
exchange status messages with selected ones of the other vehicles. 

In one embodiment, each computing unit includes an EEEE 802. 1 1 node 
and exchanges data using an SNMP-denved protocol. Desirably, each node is Internet 
addressable, such as by the IPv6 standard for example. 



- 5 
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In still another of its aspects, the present invention provides a vehicle 
comprising an onboard computing unit which is operable in a first phase to broadcast 
enquiry messages in a regton surrounding the vehicle, a second phase to receive reply 
messages from computing units of other vehicles in the region, and a third phase to 
exchange status messages with computing units of selected other vehicles. 

Preferably, the vehicle is operable in a fourth phase to exchange data with 
a remote site in the form of a non-mobile gateway, which routes communications 
between a wireless mobile data link and a non-mobile network. 

In one embodiment, the computing unit includes an IEEE 802. 1 1 node and 
can exchange data with other computing units using an SNMP-denved protocol. 

In still another of its aspects, the present invention provides a hybrid 
communications system, comprising a wired network portion and a wireless network 
portion, each having a network connection node, at least two data link means between the 
network connection nodes, and a switch means for enabling either of the data links for 
data exchange between the connection nodes. 

Preferably, the system further comprises measurement means for 
measuring impedance on the data links, the switch means being responsive to the 
measurement means for enabling the data link having a lower impedance. 

In yet another of its aspects, the present invention provides a vehicle 
communications system having a controller, a data pathway joining the controller with a 
plurality of vehicle components and means for establishing a data link with other vehicles 
within a given region surrounding the vehicle in order to exchange data therewith. 
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In still another of its aspects, the present invention provides an operational 
event-reporting system for use by a plurality of neighboring vehicles to support IVHS 
comprising a plurality of communication units, each onboard a corresponding vehicle to 
collect operational data from selected components thereof and to exchange data with the 
communication units of one or more of the neighboring vehicles. 

Preferably, the system is capable of exchanging data related to the 
operation of the neighboring vehicles, for example. GPS position and heading, vehicle 
speed, braking or the like. Data of this kind can be useful for vehicle telemetry systems 
to provide, for example, collision avoidance. 

In yet another aspect of the present invention, there is provided a method 
of exchanging data between a vehicle and at least one remote site, comprising the step of 
providing the vehicle with a transmitter and receiver capable of transmitting and 
receiving messages under an SNMP protocol. Preferably, the data exchange site includes 
a neighboring vehicle or an access point for a wired network, for example. 

In one embodiment, the method further comprises the steps of: 

- exchanging discovery signals with neighboring vehicles; and 

- exchanging status data with selected ones of the neighbouring vehicles. 

In yet another of its aspects, there is provided a system for transferring 
data between a vehicle and another data exchange site, comprising a pair of data link 
means, wherein at least one of the data link means has a varying signal impedance level 
and switch means for switching between the data link means so that the data is transferred 
on the data link means having the least impedance. 
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In yet another of its aspects, the present invention provides an extension of 
the hybrid RF packet network comprising: 

(i) an interface to an IEEE 802. 1 1 data link integrated in the Hybrid Network 
Radio; 

(ii) an EEEE 802. 1 1 Access Point acting as an IPv6 router and a foreign 
mobility agent for mobile nodes implementing Mobile EP; 

(iii) an interface to a non-wireless subnetwork from which the Hybrid Network 
Gateway can route mobile-terminated traffic through an IEEE 802.1 1 Access 
Point; and 

(iv) a cluster intelligence module, based on the establishment of ad-hoc 
networks between a vehicle and its IEEE 802.1 1 neighbors. 

Preferably, mobile nodes that are ATP-enabled can exchange Internet 
traffic with regulatory agencies over license-free wireless data links (EEEE 802. 1 1 ) 
whenever connections are established with Mobile IP-enabled Access Points. The cluster 
intelligence module is operable using ATP from vehicular node to acquire information 
about the automotive behavior of any of its discovered neighbors. 

In another of its aspects, the present invention provides a method of 
exchanging data between a mobile node and an access point on a communications 
network, comprising: 

a) a step for providing at least two wireless data links between the mobile 
node and the access point; 
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b) a step for measuring impedance on each data link; and 

c) a step for transmitting said data across the data link having the lowest 
impedance. 

In still another aspect of the present invention, there is provided a method 
of exchanging data between a motor vehicle and a remote station, comprising: 

a) a step for providing at least two data links between vehicle and said 
station; 

b) a step for measuring impedance on each data link; and 

c) a step for transmitting said data across the data link having the lowest 
impedance. 

In still another aspect of the present invention, there is provided an inter- 
vehicle communications network, comprising at least two motor vehicles, each having an 
on-board control system, the system including monitoring portion and a spread spectrum 
radio portion and which is operable to exchange useful vehicle operational data with the 
control system of the other vehicle. 

Preferably, each monitoring portion is capable of registering a vehicular 
event and each control system may. if desired, be operable with other vehicular override 
systems to override a vehicle function according to a vehicular event. Desirably, each 
control system includes a memory portion for stonng vehicle operational data of the other 
vehicle. 
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In one embodiment, the network includes at least one, preferably more 
than one. remote station is located along a road way on which the vehicles are traveling. 
The remote station includes a spread spectrum radio portion to be capable of exchanging 
data with either of the vehicles and is also preferably an internet or intranet or other 
network access point. 

Conveniently, the vehicles are operable to exchange data using an SNMP- 
denved protocol and each vehicle is capable of monitoring vehicular events in its own 
region. 

In still another aspect of the present invention, there is provided a motor 
vehicle comprising an onboard general purpose computer and a spread spectrum radio, 
the computer operable to monitor a number of predetermined operating characteristics of 
the vehicle, the spread spectrum radio operable to establish a data link with a radio in at 
least one other neighbouring vehicle, wherein the computer is capable of identifying at 
least one vehicular event from data received on the data link. 

In still another aspect of the present invention, there is provided a 
computer program product for operating a programmable computer system on board a 
motor vehicle, wherein the system includes a spread spectrum radio, comprising a 
computer readable medium including the computer executable steps of: 

- instructing the radio to issue a signal to a region surrounding the motor vehicle; 

- monitoring the radio for reply signals from other vehicles in the region: and 
when a reply signal is received from another vehicle, 

- establishing a data link with the other vehicle, and 
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- exchanging operational data with the other vehicle over the data link. 

In yet another of its aspects, there is provided a mobile automotive 
telemetry system for installation on-board a vehicle, comprising: 

(i) diagnostic means for monitoring operational functions of the vehicle and 
generating operational information; 

(ii) memory for storing the generated operational information; and 

(iii) a server, in communication with the diagnostic means and the memory, the 
server composing: 

(a) means to receive a request from a remote client for the generated 
operational information; 

(b) means to retrieve the generated operational information from the 
memory means; and 

(c) means to transmit the generated operational information to the remote 
client. 

Preferably, the means to receive and the means to transmit are wireless 
communication means. 

In one embodiment, the system further comprises an Internet access means 
and a means to transmit generated operational information to a remote client, in absence 
of a request from the client, when the generated operational information satisfies 
predetermined criteria. Preferably, the Internet access means is compliant with IP V6 
internet protocol and allows the server to act as a mobility agent. Preferably, the system 
further comprises means to interface to a global positioning system (GPS) receiver. 

- 11 - 
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As described hereinbelow. the Applicant's pending application, serial 
number 09/140.759 filed August 26, 1998 entitled SYSTEM AND METHOD FOR 
PROVIDING MOBILE AUTOMOTIVE TELEMETRY discloses a system and method 
for automotive maintenance telemetry. The system functions on a client-server 
architecture enabling a remote client to request information from an on-board diagnostic 
(OBD) module in a vehicle, such as that commonly referred to as the Electronic Control 
Module (ECM) The OBD module performs the role of 'server by being programmed to 
interface with the ECM, and with any other sources of diagnostic information and then 
communicates the data to a requesting client, such as OEM suppliers, dealers or 
regulatory agencies. 

The location of the requesting client can dictate how the data is delivered. 
For example, in the Applicant's co-pending PCT Application PCT/CA98/00986 filed 
October 23. 1998 entitled TELECOMMUNICATIONS SYSTEM, the OBD module may 
select a path of least impedance to deliver the data to the client. For example, where the 
client is land-based, such as, for example an emissions regulatory body, the OBD module 
may deliver the data either through a conventional RF packet network (such as over a 
cellular phone connection) or through an RF packet network using a Hybrid network as 
described in the above mentioned PCT application. However, the requesting client may 
in fact be another vehicle traveling along the same roadway as the server vehicle and 
may request data for such things as vehicle speed, braking, position and the like. The 
OBD module may convey the data over a wireless data link such as over the band known 
as the "spread spectrum band" as is described in the applicant's co-pending provisional 
application serial number 60/139,573 filed June 17, 1999, entitled VEHICULAR 
TELEMETRY and as specified in the EEEE 802. 1 1 standard. 

IEEE 802 Standards Family 
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The IEEE 802 family of standards specifies the methods for 
implementation of local area networks (LAN's) using both wired and wireless media. 
The IEEE 802.1 1 standard specifies the medium access control (MAC) layer and three 
separate methods for implementation of the physical layer (PHY) as a wireless medium. 
IEEE 802. 1 1 is intended to ensure inter-operability between multi-vendor equipment 
operating in wireless networks. As such, it is the basis for the interface specified herein 
enabling vehicular computing equipment to establish license-free data links with fixed 
stations. 

The IEEE 802.1 1 standard specifies three different physical layers, use of 
Infrared light. Direct Sequence Spread Spectrum and Frequency Hopping Spread 
Spectrum. The band utilized for the Spread Spectrum technique is ISM (Industrial. 
Scientific and Medical) RF band, which is free of regulatory licenses in most of the 
world. Communications in the Spread Spectrum involve a coordinated change in 
frequencies, either by a "Direct Sequence" or a "Frequency Hopping" format. 

The IEEE 802.2 standard, called Logical Link Control (LLC), specifies a 
method for addressing and control of the data link, independent of the underlying 
medium, and is applicable to all types of LAN's defined within the IEEE 802 family. 
Both 802. 1 1 and 802.2 are incorporated herein by reference. 

The IEEE 802. 1 1 does not specify the handoff mechanism for a mobile 
node to roam from one Access Point to another. When both the IEEE 802. 1 1 client and 
Access Points incorporate IPv6 implementations, including ND (Neighbour Discovery) 
and RD (Router Discovery), roaming clients are able to bind to (or to establish a data link 
with) the Access Points, where the latter take on the role of Foreign Mobility agents as 
defined in [3]. The Access Point acts as a mobility agent for the roaming client. The 
Mobile IP specification therefore provides a solution to the lack of an IEEE 802. 1 1 
mechanism for coordination of roaming (handoff) between Access Points. 

- 13 - 



SUBSTITUTE SHEET (RULE 26) 



WO 00/79727 



PCT/CA00/00712 



Automotive Telemetry Protocol 

In one embodiment, data is exchanged between vehicles using a protocol 
herein called "Automotive Telemetry Protocol" (or ATP) and is based on Simple 
Network Management Protocol (or SNMP). The latter is commonly used in data 
communication networks to monitor and control switching equipment. SNMP is specified 
in [2], the contents of which are incorporated herein by reference. ATP is intended to 
function according to the same client-server model as SNMP, wherein the client issues 
the requests for information and the server issues the responses. Although the ATP 
makes use of the same formats of the requests and responses as SNMP, ATP implements 
a novel set of "object identifiers" which are required to encompass the OBD data 
requested, in contrast to the telecommunications equipment data exchanged in SNMP 
For example, the object identifiers may, in this case, correspond to nodes on the 
Controller Automation Network (CAN) bus in the vehicle, such as the ABS system, 
emission control system and the like. 

SNMP and its derivative defined herein, ATP, are efficient 
request-response mechanisms which require less bandwidth than Web-based data 
exchanges between client and server. The payload (i.e. the useful telemetry data) can be 
encapsulated within the maximum allowable frame sizes of the underlying data links. 
These protocols therefore do not require the overhead associated with fragmentation at 
the source, and properly sequenced reassembly of large messages at the destination. 

IPv6 and Mobile IP: Dynamic topology of the new Internet 

The well known "Mobile IP" specification defines a protocol that enables 
IPv6 datagrams to be transparently routed to mobile nodes in the Internet. This 
specification is provided in Internet Engineering Task Force, Perkins, C. fed), " IPv6 

- 14- 
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Mobility Support", March 1995 [3], the contents of which are incorporated herein by 
reference 

By definition, a mobile node is one that can connect to the Internet 
through any one of a variety of different access points, called mobility agents. Each 

5 mobile node is registered with one and only one mobility agent, called a home agent. 

When a mobile node attaches itself to the Internet through an access point other than its 
home agent, the access point is called a foreign agent. The Mobile IP protocol 
incorporates a mechanism for mobile nodes, when they are attached to a foreign agent, to 
register a "care-of-address" with the home agent. Thus, datagrams routed to the mobile 

10 node through the home agent can be re-routed to reach the mobile node at its current 
network location. 

When a mobile vehicle is already equipped with radio-modem technology 
that provides a unique address on a wireless network, it is possible to assign a unique 
Internet address that can be reached through an EP router between the wired Internet and 

15 the wireless network. This is described in the Applicant's co-pending PCT Application 
PCT/CA98/00986 filed October 23, 1998 entitled TELECOMMUNICATIONS 
SYSTEM. This represents a static Internet topology because, although the vehicle is 
mobile, the IP router through which it is reached never varies. The topology of the 
wireless network itself is dynamic and supports the roaming required for a vehicle to 

20 establish contact with the network through different base stations and regional switches. 
However, at the EP level, this dynamic topology is not visible. 

In contrast, the Mobile IP extension to the IPv6 specification allows for a 
dynamic network topology. It lends itself to the task of enabling communication from the 
Internet to a mobile vehicle through different foreign mobility agents. In the context of 
25 vehicular mobility, the role of mobility agent can potentially be adopted by any Internet 
node that has the ability to dynamically create a data link with a vehicle. To date, the 
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most efficient means available by which such data links can be quickly established are 
defined by the IEEE 802 J 1 specification for wireless LAN's (Local Area Networks). 

A data link can be established between a mobile EEEE 802. 1 1 node, 
implemented in the vehicle, and any fixed IEEE 802.1 1 node, called an Access Point, 
provided that both nodes incorporate full implementation of the IPv6 protocols, 
specifically the Neighbor Discovery protocol, (hereinafter referred to as ND) and the 
Router Discovery protocol (RD) ND and RD are specified in Narten, T., Nordmark, 
and W. Simpson, " Neighbor Discovery for IP Version 6 (IPv6)", RFC 1970, August 
1 996. [5], the contents of which are incorporated herein by reference. For every interface 
to a datalink implemented in an IPv6 node, in this instance a wireless IEEE 802 datalink, 
ND is required to ensure that neighbors, defined as other nodes which are k 'on-link" (i.e., 
capable of communications on the same datalink) can be dynamically identified as they 
appear. This is accomplished through the use of periodic broadcasts on the wireless 
medium, called Neighbor Solicitations, to which any recipient of the broadcast is required 
to respond, in such a way as to enable the broadcaster to identify the responder with a 
unique IPv6 address. An implementation of ND typically maintains a table of neighbors 
that dynamically changes as each new cycle of neighbor solicitation either reveals a new 
respondent or loses, through lack of response, a (previously) existing neighbor. RD is a 
specialization of ND. ensuring that on-link nodes capable of routing IP datagrams to other 
sub-networks, can be discovered. 

Thus, the vehicle communications system, according to one embodiment 
of the present invention, is capable of handling the Mobile IP protocols over an IEEE 
802. 1 1 data link and. as a consequence, is capable of delivering vehicular diagnostic data 
under the requirements of OBD-in and of exchanging a wide range of data, including e- 
commerce transactions and the like, as well as data needed for such things as Intelligent 
Vehicle Highway Systems. 
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According to one aspect of the present invention, each vehicle has one of 
a number of Hybrid Network Radios (as described in Applicant's PCT patent 
application PCT/CA98/00986) which can effectively communicate with one another 
using the Mobile EP protocol over one or more wireless LAN's. In this particular case, 
5 then. Internet-addressable vehicles may roam between wireless LAN's and still be in the 
network. 

Ad Hoc Network 

By making the vehicular computers Mobile IP-enabled as described in 
utility patent application 09/140,759 filed August 26, 1998 (entitled SYSTEM AND 

1 0 METHOD FOR PROVIDING MOBILE AUTOMOTIVE TELEMETRY) as described 
herembelow, each vehicular system may be connected to the Internet through the EEEE 
802. 1 1 data link. When two or more vehicular computer systems are equipped with IEEE 
802. 1 1 interfaces and where each operates on the same frequency changing format, that is 
by using either Direct Sequence Spread Spectrum or Spread Spectrum Frequency 

15 Hopping, they can then communicate amongst themselves and thereby create an "ad hoc" 
network between them. The so-equipped vehicular systems can now support IP 
Neighbor Discovery 7 , which enables all vehicles within range to recognize each other as 
"on-link" IPv6 nodes, provided that the adjacent vehicular systems are also compliant 
with IPv6. This means that useful information may be exchanged between adjacent 

20 vehicles by the use of spread spectrum frequencies. Therefore, the same UDP/EP 

mechanism, used to permit telemetry traffic to be encapsulated in IPv6 datagrams from 
any vehicle to a fixed-location host, can be used to permit telemetry traffic to be 
exchanged between vehicles. 

This ad hoc network also enables mobile vehicles within range of each 
25 other to establish a "cluster intelligence", which is defined, within the context of the 

present invention, as an infrastructure for interactive vehicular control based on the same 
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request/response telemetry architecture described in utility patent application serial 
number 09/140.759 filed August 26, 1998 (entitled SYSTEM AND METHOD FOR 
PROVIDING MOBILE AUTOMOTIVE TELEMETRY) 

In one embodiment, the system comprises the following components: 

( 1 ) Hybrid Network Radio, as specified in [4], supplemented by: 

(a) Wireless LAN interface compliant with: 

(i) IEEE 802.2 

(ii) IEEE 802.11 interface 

(b) IPv6 modules including: 

(i) IPv6 

(ii) IVMPv6 

(iii) IP Neighbor Discovery and Router Discovery 

(iv) Mobile IP 

(2) IEEE 802 Access Point as an IPv6 Router 

( 3 ) Cluster Intelligence Module 

The cluster intelligence module is intended to provide a means by which 
Intelligent Vehicle Highway Systems (IVHS) can be implemented without the need for 
electronic winng of the highway infrastructure. Cluster intelligence is based on the 
establishment of an ad hoc network connecting vehicular Hybrid Network Radios. 
Whereas the primary goal of the Hybrid Network Radios is to enable least-cost IPv6 
communications of telemetry data required by environmental regulations, an ad hoc 
network among and between Hybrid Network Radios provides a platform on which 
vehicles can transmit real-time operational information to each other. 
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As a result, in those instances where the aim of IVHS is to control the 
spacing and speed of vehicles on highways, and therefore the volume of vehicular traffic 
flow, cluster intelligence offers a low-cost alternative to the conventional ideas proposed 
for highway infrastructure upgrades. 

Figure 1 shows the classic relationship defined in traffic engineering 
between speed and volume on a road link. There is an optimum point along this curve 
where the volume is maximized. The speed at this point is defined as the "free flow" 
speed. Below this speed, traffic flow is conjested. Above this speed, the spacing between 
vehicles required for safety results in profligate use of the roadway. At any point along 
the curve, the volume-speed relationship represents the most efficient inter-vehicle 
spacing, given the braking distance required for safety, which can be achieved. 

In one embodiment, the peer-to-peer telemetry architecture of [1] and as 
described below, supports the ability of vehicles to adapt their speeds in accordance with 
the optimal volume-speed relationship. The ATP protocol used between vehicles enables 
each one to determine, among other things: 

(a) The distance(s) between it and the vehicle(s) immediately ahead of it (using 
GPS position and heading reports). 

(b) The speed(s) of the vehicles immediately ahead of it. 

(c) Application of brakes. 

This information provides the enabling technology for all vehicles to 
engage in a cooperative effort to maximize traffic flow on electronically enhanced 
highways. 
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The term "Impedance" used herein is intended to be a measure of the 
"costs" of sending a datagram across a data link. This cost can include the monetary 
charges associated with the transmission of data across a wireless data link and are 
typically imposed by the operator of the wireless data network, as well as other factors 

5 such as . for example, the size of packet and the time of day, which of course will change 
over time. As is described in the PCT Application serial number PCT/CA98/00986 filed 
October 23. 1998 entitled TELECOMMUNICATIONS SYSTEM, the Impedance 
governs the functionality of the RF path switch. As impedance changes, the output of the 
RF path switch (i.e. the routing decision) can change. The sections entitled Error 

1 0 Reporting and Airlink Status Reporting describe the mechanisms whereby changes in 
impedance are reported to the RF path switch module. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Several preferred embodiments of the present invention will be provided, 
by way of example only, with reference to the appended drawings, wherein: 

1 5 Figure 1 is plot of traffic volume versus speed on a road link; 

Figure 2 is a schematic view of a vehicle communications system. 

Figure 2a is a schematic view of one aspect of the vehicle communications system 
of figure 2. 

Figure 3 is another schematic view of the vehicle communications system of 
20 figure 2. 

Figure 4 is a schematic view of one segment of the vehicle communications stem 
of figure 2. 
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Figure 5 is a schematic view of another segment of the vehicle communications 
system of figure 2. 

Figure 6 is a schematic view of still another segment of the vehicle 
communications system of figure 2. 

Figure 7 is schematic representation of a system in accordance with one 
embodiment of the present inventions 

Figures 8 a) and 8b) are schematic representations of a system according to still 
another embodiment, and 

Figures 9. 10. 11. 12, 13, 14 and 15 are schematic views of portions of still 
another embodiment. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

Figure 2 illustrates a communications network for exchanging data 
between a plurality of vehicles, including vehicles 10 and 12 on a highway shown at H. 
Each vehicle has a computing unit 10a and 12a. the latter of which is shown 
schematically in figure 2a. Each computing unit has aprocessorlOc which is connected 
via a serial port to a GPS receiver lOd, an IEEE 802.1 1 spread spectrum unit lOe, a cell 
packet data unit lOf capable of broadcasting and receiving data over a cell packet data 
network and a memory unit lOg. If desired, the components of the computing unit may 
be integrated on the same board using application specific integrated circuits (ASIC's), as 
described hereinbelow and in U.S. provisional application serial number 60/148.270. 
filed on August 1 1. 1999 and entitled VEHICULAR COMPUTING DEVICE. 
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Referring to figure 2, each computing unit 10a, 12a broadcasts ND and 
RD messages in a region surrounding the vehicle as shown by the circles 10b, 12b. In the 
example shown in figure 1 three other similarly equipped vehicles labeled 14a to 14c are 
all within the region 10b and therefore are capable of receiving the broadcast enquiry 
messages from the vehicle 10. The vehicles 14a to 14c issue reply messages which are 
received by the vehicle 10. Similarly, vehicles 14b to 14f are within the region 12b of the 
vehicle 12 which in turn receives reply messages from them. These messages may 
include such things as vehicle speed and GPS information as well as status indicators 
such as acceleration or braking. In this manner the computing units 10a, 12a are able to 
determine the position and movements of neighboring vehicles. 

Thus, the number of vehicles in the corresponding region for each vehicle 
will change over time with the traffic pattern. In this case, the computing unit for each 
vehicle can retain status data for each target vehicle while the vehicle is in the region and 
then erase the data for those vehicles that have left the region. The memory unit lOg can 
have allocations for storing data for each vehicle while the processor can manipulate the 
data to determine if any action needs to be taken. The processor also receives data from 
the ECM lOh which can include such things as emissions, braking, acceleration, speed 
and the like, that is. any function of the vehicle which is being electronically sensed, 
monitored or measured. Optionally, the processor may also pass off, to other vehicle 
systems, braking or other override commands for controlling the vehicle if necessary. 

Located along the highway are a number of access points which are 
routers to a fixed communications network, in this case spread spectrum base stations. 
One of the access points is shown at 16. The access point 16 issues router advertisement 
messages with a region shown by the circle 16a. Therefore, vehicle 12. in the instant of 
time represented by the figure 1. receives the advertisements. In this example, the vehicle 
computing units 1 0a and 12a as well as the access point 1 6 are IPv6 addressable. 
Therefore, the vehicle 12 and the access point 16 may then exchange data which may 

- 22 - 



SUBSTITUTE SHEET (RULE 26) 



WO 00/79727 



PCT/CA00/00712 



include internet email and the like. The access point 16 may also convey status request 
data from a clean air regulatory body to the vehicle 12 which may then return the status 
data to the regulatory body through the access point 16 if the vehicle is still in its region. 

Base station 1 8 provides a wireless data link to a proprietary RF packet 
network, for example that known as the MOBITEX network, or the like. This is a 
different data link from the spread spectrum data link operating at the access points 1 6. 
The computing units exchange data with the station 1 8 via the cell packet data unit lOf. 

The GPS information from the neighboring vehicles may, for example, 
include Differential GPS (D-GPS). In the latter cases, the vehicle may more accurately 
measure the position of neighboring vehicles, relative to a reference GPS position which 
may be broadcast, for example, from the access point 16. 

Global System 

Figure 3 shows the overall system architecture. As will be described, 
Figure 3 illustrates how the IEEE 802 data link is incorporated into the hybrid mobile 
packet network and shows the path of Mobile IP communications between a mobile node 
shown at 1 0 and its home mobility agent, i.e.. the Hybrid Network Gateway 230. Mobile 
node 10 is an embedded vehicular computing device functioning both as an OBD server 
[ 1 ] and as a Hybrid Network Radio [2]. The Hybrid Network Radio functionality is 
implemented through the interface 40 to the hybrid mobile packet network 250. 

Fixed node 16 is a wireless communications base station implemented in 
accordance with the definition of a "foreign (mobility) agent" contained in [3]. Mobile 
node 10 and fixed node 16 share the same IEEE 802 wireless data link 15. which, from 
the perspective of the mobile node 1 0 and as will be described further below, is integrated 
as a "zero-cost" data link in the interface 40 to the hybrid mobile packet network 250. 
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Fixed node 1 6 may be. for instance, an embedded computing device permanently 
installed near a roadway and connected to a data communications network 210 via a 
stationary (non-mobile) backbone 220. 

When a mobile node 1 0 comes sufficiently within range of a fixed node 1 6 
to establish an EEEE 802 data link, Internet traffic, in the form of IP datagrams, may flow 
from the vehicle to any address in the Internet. This is called "mobile-originated" traffic. 
"Mobile-terminated" traffic can only reach the vehicle once the Mobile IP "care-of 
address*' registration has been completed. This procedure, specified in [3], allows the 
mobile node to notify its "home (mobility) agent" that it can be reached through the 
foreign (mobility) agent embodied in the fixed node 16. As a foreign (mobility) agent, 
fixed node 16 is, by definition, an IPv6 router. 

The home mobility agent for mobile node 10 resides in the Hybrid 
Network Gateway 230. A Hybrid Network Gateway (HNG) is the stationary equivalent 
of a Hybrid Network Radio and is defined in [2]. HNG 230 has an abstract interface 
240 to the hybrid mobile packet network 250, through which it can route Internet traffic 
to a mobile node. In order to ensure least-cost routing to a mobile node that has 
registered fixed node 16 as its care-of- address, interface 240 must also incorporate the 
data link associated with stationary backbone 220. This extends the hybrid mobile packet 
network to include a stationary data link. 

In other words, the system has the capacity to carry out least-cost transfer 
data between the Hybrid Network Gateway 230 and the mobile node 10 in one of three 
routes: 

i) via the data link 1 5, the fixed node 16. the data link 220 and the stationary 
non-mobile data link 210. or alternatively 
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ii) through the hybrid mobile packet network 250. which itself can provide least 
cost switching between : 

a) a satellite Packet Network; or 

b) an RF Packet Network. 

Ipv6 Communication Protocol Stack 

The IPv6-based communications software infrastructure for a telemetry 
system in accordance with this example is shown in Figure 4. Figure 4 is a representation 
of the Hybrid Network Radio incorporating interfaces to an arbitrary number of RF 
packet networks, including an interface to a wireless IEEE 802 data link, integrated into a 
single abstract data link as specified in [4]. Figure 4 also shows the relationship between 
the Hybrid Network Radio and an EEEE 802. 1 1 Access Point incorporating an IPv6 router 
implementation. In this scenario, mobile-originated Internet traffic (datagrams emanating 
from the Hybrid Network Radio) can be routed through the access point or alternatively 
through the hybrid mobile packet network 250 depending on 'cost'. Mobile node 10 is an 
IPv6 (Internet) node consisting of a protocol stack 20 in accordance with definition of a 
Hybrid Network Radio provided in [4]. Fixed node 16 is an IPv6 (Internet) router 
consisting of the router-specific equivalent of protocol stack, labeled 21 . The 
components of protocol stack 20 are: 

(i) a combined RF packet network 30 that unifies all the wireless data links 
available to mobile node 10 into a single abstract data link capable of least-cost 
switching; 

(ii) an IPv6 module 60. in accordance with [6], the contents of which are 
incorporated herein by reference: 
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(iii) an ICMPv6 module 70. in accordance with [7], the contents of which are 
incorporated herein by reference, that provides the assembly and parsing 
mechanisms for the specific datagrams required by ND: 

(iv) a Neighbor Discovery (ND) module 80, in accordance with [5], that 
enables mobile node 10 to dynamically discover other "on-link" mobile nodes, 
i.e.. other vehicles capable of communicating on the same IEEE 802. 1 1 medium; 
and 

(v) a Router Discovery (RD) module 90, in accordance with [5], which 
enables mobile node 10 to discover dynamically IPv6 router 16. 

Both the ND and the RD protocols require the broadcasting of, 
respectively, neighbor and router advertisement datagrams, defined in ICMPv6. These 
datagrams are sent to the interface 40 to the combined RF packet network 30. Broadcast 
datagrams can only be transmitted on data links that are broadcast-enabled. Typically, 
wide area RF packet networks do not support broadcasting initiated by subscribers, 
although they often allow multicasting to selected groups of mobile subscribers Since 
IEEE 802. 1 1 depends on broadcast frames to establish the data link, it should identify' 
itself to interface 40 as broadcast-enabled, whereas all other RP packet networks 
incorporated in the combined packet network 30 should report that they are not 
broadcast-enabled. The intelligent switching mechanism of this interface, which ensures 
that datagrams are transmitted over the least-cost data link, will therefore switch all 
mobile-originated broadcast datagrams over the IEEE 802.1 1 data link. 

In case of overlapping of the coverage areas of two or more Access Points, 
a mobile node may receive router advertisements from more than one fixed station, in 
response to its broadcast of router solicitations, providing it with alternative on-link 
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routes to use for outbound datagrams. Both neighbor and router discovery should rely 
primarily on unsolicited neighbor and router advertisements. 

Registration of the "care-of-address" provides a means for requests from 
the OBD telemetry client to reach a mobile node via the foreign mobility agent, which, by 
definition, is an IEEE 802 access point. The maximum acceptable impedance values 
associated with these requests can be set such that the mobile-terminated ATP traffic that 
would otherwise incur costs traveling over RF packet networks, can be deferred until the 
"care-of- address" is registered with the home address. 

Cluster Intelligence 

The cluster object as an ATP client is a specialization of the generic 
SNMP client using the UDP/IP protocol. The ATP allows for message passing to the 
cluster object. 

The establishment of an IEEE 802.1 1 ad-hoc network as a ^'mobile 
cluster" in accordance with the present example is shown in Figure 5. Mobile node 10 
incorporates the User Datagram Protocol (UDP) module 100 and the ATP module 1 10. 
An equivalent mobile node 1 1 , with equivalent UDP and ATP modules 1 0 1 and 111, 
respectively, can interact with mobile node 10 such that the automotive behavior of 11 is 
known to 10. This is accomplished through the mechanism of an ATP request issued by 
10 to 11 and an ATP response from 11 to 10. 

The interaction between any two mobile nodes is managed by a "cluster", 
which is an active object that registers with the ATP for reports from neighboring 
vehicles. Cluster 120 has container 130 of neighbors, or more precisely, "images" of 
neighbors. These neighbors are placed in the container when detected by the ND 
mechanism operating over the IEEE 802. 1 1 data link, as shown in Figure 4. By 
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propagating the discovery mechanism in ND module 90 upwards through the UDP/IP 
stack. Node 1 1 becomes a member of Node 10's cluster when the ATP signals the cluster 
that a new neighbor has appeared. (The whole process can be repeated for mobile node 
12, which becomes a second neighbor of node 10). 

Registration of neighbors discovered through the ND requires an 
implementation of IPv6 that can be asynchronously notified of ND, which requires a 
"callback" method of IPv6 to be invoked when the neighbor's response to a solicitation 
request is being processed. The conventional processing of such a response is simply to 
update the cache of on-link neighbors known for that interface. However, the 
requirements of cluster intelligence are that dynamic neighbor identification propagate 
upward from the subnetwork layer to an application port of the UDP/EP protocol stack. 

In this example, cluster communications over wireless data links is 
intended to take place only over the license-free spread spectrum band. The cluster object 
itself has "no knowledge" of the fact that there are alternative radio paths between 
vehicles. However, when the cluster asks each new neighbor to transmit GPS position 
reports and automotive events in which it is interested, both the requests as well as the 
responses will travel only over zero-cost links - which are precisely the same links over 
which the ND operates. In others words, by virtue of the least-cost mechanism described 
in [4], a license-free wireless data link will always be the data link over which the ND 
datagrams are transmitted. ND can and should be configured such that its maximum 
acceptable impedance level can only be supported by the license-free links. ND will 
therefore only discover neighbors that are on the license free links and cluster traffic that 
follows from this will travel only over these links. 

Provided that an implementation of cluster 130 is compliant with the 
requirements for the interface to the module ATP 110, already specified in [1], the 
internal behavior of the cluster may vary depending on the design objectives and 
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implementation style for a specific vehicular device. The precise design of the methods 
(behavior) or the specification of other methods intended to process (and act on) 
information reports from neighboring vehicles is not within the scope of the present 
invention. 

Process Architecture 

Figure 6 illustrates the process architecture of the device comprising the 
mobile node. ATP client process 300 is part of the cluster intelligence module. Figure 6 
illustrates the architecture of the processes, running on top of the UDP/IP stack, that 
provide all of the functionality of the system. These processes are: 

(i) an OBD process, with the behavior of an ATP server: 

(ii) a Cluster Intelligence process with the behavior of an ATP client; 
(lii) a Mobile IP process, with the behavior specified in [3]; and 

(iv) a diagnostic data acquisition process. 

ATP is registered with UDP module 330 through the application port 305. 
Similarly Mobile IP process 310, which is responsible for registration of care-of- 
addresses (i.e.. addresses of foreign mobility agents) with home mobility agents, is 
registered with UDP module 330 through the application port 3 1 5. The ATP server 
process 320, registered with UDP module 330 through port 325, provides access to the 
Diagnostic Information date Base (DIB) 340. This data base, similar to the Management 
Information data Base (MIB) used by SNMP (from which ATP is derived), contains all of 
the on-board diagnostic information obtained from the data acquisition processes 350 
(Analog and digital signal processing), 360 (CAN-bus data processing) and 370 (GPS 
receiver data processing). 

Whereas the present invention does not limit the scope or charactenstics of 
possible cluster implementations, the behavior recommended for effective use of the ATP 
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to implement cluster intelligence within each vehicle is described by the pseudo-code 
below. The cluster is defined as an object that owns an ATP client process with a set of 
methods corresponding to the handling of each of the possible messages that could be 
received through the ATP. 

In one example, the cluster's ATP client process would be: 

CI usterProcess ( ) 

i 

while f TRUE ) { 

pointer _event _object = Wait jOueue _Event ^Signalled _By _ATP() ; 
pointer _event_object->Handler(); II behavior of event object 
destroy _event( pointer _event_objecti 

} 

} 

The cluster process blocks on an event queue, registered with the ATP. to 
which the ATP can append events relevant to the cluster process as they occur. These 
events are removed from the queue and processed on a first-in first-out basis. All events 
are treated as objects derived from a common base class within a virtual "handler" 
method, the internal behavior of which varies for each type of event. The handler method 
of the event is invoked by the cluster process when the event is removed from the queue. 

The primary type of event which the ATP should signal to the cluster is a 
GPS position report from a neighbor. This implies, of course, that all nodes on the ad- 
hoc IEEE 802. 1 1 network should broadcast GPS position reports. Other on-link nodes 
receiving these broadcasts should propagate the reports upward through the protocol 
stack to the ATP, which should signal an Event _Gps Report to the cluster. 
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Event _GpsReport_Handler() is the method invoked when the GpsReporr signaled oy the 
ATP is removed by the cluster process from its queue. The inputs to this method are: 

(i) ID _Remote_Vehicle - which should be the unique IP address of the 
vehicle: 

(ii) GpsPosition - which is a latitude-longitude coordinate pair, determined by 
the GPS receiver of the remote node and contained in the payload of the UDP 
segment received from the remote; and 

(iii) GpsHeading - which is a heading determined by the GPS receiver of the 
remote node and contained in the payload of the UDP segment received from the 
remote. 

Event _GpsReport_Handler ( ID_Remote_Vehicle, GpsPosition, GpsHeading J 

f 

Remote ^Vehicle = GetRemotef ID _Remote_Vehicle) ; 
Proximity = CompareGpsfRemote _Vehicle, GpsPosition, 

GpsHeading j; 

IffProximity ) { 

AtpRequest( Remote Vehicle, speed, frequency, duration, amplitude ); 
AtpRequest( Remote ^Vehicle, foot brake, 0, 0, 0 ); 

} 

} 

Event _GpsReport_Handler carries out the following functions: 

(i) Invokes the private function GetRemote using the input 
ID_Retnote_Vehicle. (The term private signifies that the function is usable only 
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by the cluster module and is not accessible to "external" software modules). This 
searches the cluster's container of remote vehicles for the object matching 
ID _Remoie__ Vehicle: 

(li) Uses the private function CompareGps to determine whether this vehicle 
is within a specified distance threshold. This function takes as inputs: 

(a) pointer to the Remote Vehicle object; and 

(b) the new GPS position and heading. 

The GPS position and heading of the remote vehicle are compared to the 
position and heading of the "local" vehicle. The "local" position and heading are 
maintained in the DEB (diagnostic information base). Since the ATP is a peer-to-peer 
protocol, cluster intelligence request/response exchanges can be symmetrical. The DIB 
can therefore be used by the ATP client to obtain GPS information for comparison with 
reports from remote nodes, as well as by the local OBD server to respond to cluster 
intelligence requests from remote nodes. 

The output of CompareGps is a boolean variable {Proximity) indicating 
whether ATP requests to this remote are warranted because the vehicle is within a 
specified distance threshold to require preventive measures if there is a sudden change in 
speed. Since the implementation of cluster intelligence is not within the scope of the 
present invention, the internal algorithm of CompareGps is not defined here. However, it 
should be noted that any implementation of CompareGps must account for margins of 
error in the accuracy of the GPS receiver where the remote position report originates. 
Furthermore, it may not be possible to distinguish between several remote vehicles 
moving in parallel in different lanes ahead of the "local" vehicle so that the identity of the 
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vehicle directly in front may remain indeterminate. The cluster intelligence decision 
algorithm may have to assume that all of these vehicles are equally important to monitor. 

If Proximity is TRUE, then ATP requests can be issued to the remote 
node's OBD server, the responses to which enable the cluster to provide decision support 
to other intelligent modules within the complete automotive system. A minimum set of 
requests could consist of speed reports, at values of frequency and duration established by 
the owner of the cluster, (i.e., one of the aforementioned automotive modules), and of 
notifications for the application of the foot brake. 



Another embodiment of the present invention is shown in figure 7 A 
mobile automotive telemetry system is shown generally at 1 10 in Figure 1 . System 410 
comprises a diagnostic means 415 for monitoring the operational functions of the vehicle 
in which system 41 0 is installed and generating operational information. The generated 
operational information may be stored in a memory 420 until required. Both diagnostic 
means 41 5 and memory 420 are in communication with a server 425 which ultimately 
controls the operation of system 410. 



Server 425 can communicate with a remote client 430 via a data link 435 
To this end. server 425 comprises a means (440) to receive a request for information from 
remote client 430; a means (445a, 445b) to retrieve the generated operational information 
from memory 420; and a means (450) to transmit the retrieved generated operational 
information to remote client 430. Server 425 is a processor which is programmed to 
respond to requests for information from remote clients and to respond to control 
commands. 



Diagnostic means 415 may be a conventional, computer-based OBD 
module which monitors various operational functions of the vehicle in which system 410 
is located. Diagnostic means 415 may, for example, monitor exhaust emissions, fuel use, 
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ignition timing, engine temperature, speed and/or distance travelled. Diagnostic means 
415 receives inputs from the various vehicle sites via a plurality of communication lines 
460 and. after interpreting the inputs and generating formatted operational information, 
passes the operational information to memory 420 via communication line 465. 
5 Diagnostic modules suitable for use in the present invention are known in the an and are 
referred to as Electronic Control Modules (ECM) or Electronic Control Units (ECU). 
The specifications for the diagnostic modules may be found in Society of Automotive 
Engineers, "On-Board Diagnostics for Light and Medium Duty Vehicle, Standards 
Manual" 1997 Edition, the contents of which are incorporated herein by reference. 

10 Memory 420 may be any conventional computer memory, the size and 

operation of which will be dependent on the nature of the operational features of the 
vehicle a user wishes to monitor. The choice of suitable memory is believed to be within 
the purview of a person of skill in the art. In one embodiment of the present invention, 
system 410 comprises a memory 420 which includes 32k of non-volatile RAM and a 

1 5 configurable amount of additional RAM, allocated at run-time from the host processor 
system. Memory 420 receives the operational information, generated by diagnostic 
means 415. via communication line 465 and stores the operational information. Memory 
means 420 is in communication with server 420 and is capable of receiving instructions 
from server 425 and sending information to server 425 via communication lines 470a and 

20 470b. respectively. As will be apparent to a person of skill in the art, communication 
lines 470a and 470b may be replaced by a single communication line if the appropriate 
communication protocol is used. 

Server 425 acts as a gateway between remote client 430 and diagnostic 
means 415 and eliminates the requirement that remote client 430 has knowledge of the 
25 specialist OBD protocols of diagnostic means 415. Server 425 in effect acts as a 

"universal translator", allowing a remote client to interact with any diagnostic means of 
any vehicle. One way of achieving this end is through the implementation of a 
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request/response protocol which acts as a proxy for the corresponding OBD protocols. 
Under this type of protocol, an abstract request from the remote client which is received 
by the server is mapped to the corresponding request under the specialist OBD protocols 
and is then transmitted on the diagnostic means or memory, as appropriate. In the other 
5 direction, the responses returned by the diagnostic means or memory to the server are 
then mapped to an abstract response which is sent back to the client. 

Such request/response protocols are known in the art and include, for 
example. IAS protocol for infrared links and UDP/IP protocol for wide area network 
communications. 

10 

Data link 435 may be any conventional communication link, including, for 
example, telephony (wired and mobile wireless), specialized mobile radio (SMR), 
infrared and satellite (both low earth orbit (LEO) and geosynchronous). Server 425 may 
be provided with the hardware and operational protocols necessary for communicating 
1 5 with remote client 430 by a variety of means, thereby not restricting communication to a 
remote client having one particular type of data link. Providing server 425 with a 
plurality of communication protocols aids in making the system of the present invention 
universally acceptable. 

In one embodiment, server 425 is provided with infrared data link 
20 capabilities. An infrared data link between the server and the remote client provides a 
local wireless method of acquiring data from an OBD module. It therefore removes the 
need for the client's equipment to incorporate a system-compatible connector (i.e, an 
OBD-connector as specified by the SAE) and to be physically joined by a cable in order 
to communicate with the system. 

25 When, for example, the client is test equipment in a garage, the use of an 

infrared data link renders possible the development of service bays where information can 
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be transferred almost instantaneously from the vehicle to the service technician's 
computer without requiring the customer to get out of the vehicle. The infrared 
connection may be achieved by attaching a serial infrared connector to a serial port on the 
server and by ensunng that there is an unobstructed path for IR transmission between the 
LED's of the infrared connector and that of the service technician's computer. 

As will be apparent, the reliability of an infrared data link is improved 
with the implementation of a robust protocol which detects transmission errors and 
avoids collisions by operating in a half-duplex fashion. Such protocols are known and 
have, for example, been implemented by computer and software manufacturers for 
incorporation in consumer electronic products such as micro-computers, modems and 
cellular phones (i.e. the IrDA stack). Suitable protocols are described in Infrared Data 
Association, "Serial Infrared Link Access Protocol (IrLAP)", Version 1.1, June 1996 and 
Infrared Data Association, "Link Management Protocol", Version 1.1, January 1996, the 
contents of both of which are incorporated herein by reference. 

Through compliance with these infrared protocols, the server achieves a 
goal of rendering client test equipment independent of the OBD protocols. Accordingly, 
any micro-computing equipment which is infrared-aware, such as a desk-top, notebook or 
palm-top (Personal Digital Assistant or PDA) can effectively become a remote client. 

In an alternative embodiment, the infrared data link may be replaced or 
enhanced by incorporating mobile wireless data links, coupled with the UDP/EP 
infrastructure for peer-to-peer client/server exchanges over a wide area network. This 
adaptation of the system extends the range of the services offered by the server beyond its 
capabilities with only the infrared connector and data link. The principles described in the 
previous sections remain the same, with the exception that access to OBD information no 
longer requires that the vehicle be moved within infrared detection range (typically 2-5 
metres) of the test equipment. The vehicle can be in any location which is reachable on 
the Internet, via a mobile data link. 
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The system of the present invention may further comprise a means to 
transmit generated operational information to a remote client in the absence of a request 
from the client, when the generated operational information satisfies predetermined 
catena. Such transmissions of the generated operational information implies that server 
25 effectively becomes a client with respect to a remote site which is capable of logging 
the transmission. This functionality can be achieved by utilizing the peer-to-peer 
communication architecture described above and is useful in, for example, 
alarm; emergency situations. 

If, for example, while monitoring the exhaust emissions of a vehicle on the 
road, the level of carbon monoxide in the exhaust gases exceeds a predetermined level, 
the diagnostic means can communicate this information directly to server 125 via 
communication line 175. Server 125 can then transmit an alarm report to a remote site 
advising of the problem. This report can be transmitted in real-time, allowing the 
problem to be dealt with immediately, rather than having to wait until the vehicle 
undergoes routine servicing and diagnosis, days or even months after the problem has 
first come to light. 

It is envisioned that the threshold values for alarms, as well as the 
frequency and duration of the alarm message, can be configured either directly at the 
server during installation or servicing, or by using remote commands from the client. 

The system described herein may also incorporate Internet access 
technology for the drivers or passengers. The existing method of Internet access for 
individual personal computers (PC) is well-known. The PC establishes a serial link with a 
computer which has a permanent Internet (IP) address. The latter computer, for the 
purposes of this description, can be called a gateway The serial link is physically either 
a direct cable connection or via a telephone circuit, using modems at both ends of the 
link. The PC does not have a permanent IP address. It is assigned a temporary IP address 
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by the gateway for the duration of the connection. Therefore, if the link is maintained via 
a telephone circuit, then the connection automatically terminates when the circuit is 
dropped and the temporarily assigned IP address ceases to be valid. 

One of the conventional methods of Internet access from a vehicle follows 
5 the technique described above, using an analog cellular phone and a cellular modem. By 
connecting the PC to the cellular modem, the driver/passenger can obtain a temporary EP 
address in the same fashion as with wired telephony. 

Another method of Internet access from a vehicle is a technology called 
Cellular Digital Packet Data (CDPD), which is a form of packet-switching overlaid on the 

10 existing analog cellular infrastructure in the United States. CDPD operates with a portion 
of the bandwidth of the analog cellular system and provides a multiple access data link 
technology within each cellular base station's territory of coverage. However, contrary to 
the method already described, the network architecture of CDPD also allows each access 
device (CDPD modem) to have its own permanent EP address. Therefore, no dial-up 

1 5 connection is required to establish the presence of the PC on the Internet. It suffices for 
the PC to be connected to the CDPD modem (which is typically in the form of a credit- 
card style PCMCIA card) for any Internet traffic from another location to reach the PC. 

IP V6 is a new version of the Internet Protocol. One of the design 
objectives of EP V6 is to enable portable computing devices (notebooks, palm-tops, etc.) 

20 to have permanent IP addresses which can be reached regardless of where the portable 
device is physically connected to the Internet. Therefore, the device could be connected, 
at different times, to both an office LAN (Local Area Network) as well as a residential 
LAN, without requiring manual intervention by a network administrator in either LAN to 
ensure delivery of Internet traffic. This is achieved by ensuring that both LAN's have at 

25 least one node (computer) which acts as a "Mobility Agent". The Mobility Agent 

incorporates software which implements EP V6 and related protocols. The purpose of the 
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mobility-related functions in this software is to ensure that roaming computing devices 
are automatically "discovered" when they establish a link to the Mobility Agent and that 
the rest of the Internet is informed of the new path which must be used to route traffic to 
the roaming device. Only those routers in the Internet which have been upgraded to 
support EP V6 will participate in this function, 

A Mobility Agent can reside in a mobile environment as well as a fixed 
LAN. This scenario is a distinct departure from the existing models of Internet access 
already described. A mobile Mobility Agent, installed in a vehicle in the form of a mobile 
computer, can effectively "host" any IP V6-enable portable computing device, provided 
that it has a wireless data link to a network which is capable of routing packets on the 
Internet, such as CDPD. The implication is that if a vehicle is equipped with a Mobility 
Agent using, for instance. CDPD. then any portable device which a driver or passenger 
wishes to use in the vehicle to obtain access to the Internet does not also need the CDPD 
modem. It only requires the IP V6 software. 

In order to equip any vehicle with IP V6 support, a hardware platform is 
required to host all of the required protocols and to provide the data links for portable 
devices trying to connect to the Mobility Agent. In order to support the SAE diagnostic 
test modes in the remote fashion described herein, the server contains all of the 
components which will also allow it to function as a mobile Mobility Agent. 

It is envisioned that the Infrared port (and IrDA protocols), which is 
primarily useful for OBD diagnostic test modes while the vehicle is stationary and being 
examined, can "double" as an in-vehicle wireless point of entry to the internet for portable 
devices operated by the driver/passengers. 

Another embodiment is shown in figures 8a. 8b which provides an 
integrated circuit board for a vehicular computing device which supports the following: 
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a) Acquisition of diagnostic data via an automotive data bus interface (or directly 
through analog and digital inputs) and storage of the data. 

b) Data communications using spread spectrum radio in accordance with the IEEE 
802. 1 1 specification for wireless local area networks. 

c) Reception of signals from Global Positioning System satellites and 
determination of position, heading and speed based on these signals. 

d) The IEEE 802. 1 1 protocol stack is implemented in an additional task executed 
by the host CPU. Depending on the choice of processing resources, the GPS 
position determination may be carried out by an additional task executed by the 
host CPU. 



In both Figures 8a) and 8b), the CPU board 510 comprises the Universal 
OBD Server host system into which both the spread spectrum modem and GPS receiver 
functions are integrated in the form of chipsets. 

In Figure 8a), spread spectrum transceiver circuitry 512 comprises the RF 
processing functions required for implementation of a spread spectrum radio modem. 
These are embodied in a series of semiconductor devices constituting a chipset for 
integration of spread spectrum radio in a host CPU board. As these devices constitute 
externally defined components that are integrated in the present invention, only those 
components that interface with the host system are numbered. 



Host CPU 520 communicates with spread spectrum transceiver circuitry 
512 through two (2) serial interfaces. Serial interface 514 handles inbound data received 
from the sequence generator 5 1 6 while serial interface 5 1 8 handles outbound data sent to 
the decimator 519. 
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The embedded software required to drive the spread spectrum transceiver 
is an implementation of the EEEE 802. 1 1 specification, executed by the host CPU. The 
functional interface between the host CPU and the spread spectrum sub-system 
corresponds to the interface between the two bottom layers of the IEEE 802. 1 1 physical 
layer architecture. The lower layer is called the Physical Medium Dependent (PMD) sub- 
layer, which is embodied in the spread spectrum transceiver circuitry. The upper layer is 
called the Physical Layer Convergence Procedure (PLCP) sub-layer, which constitutes 
the lowest level of the protocol stack implemented in software to be executed by the host 
system. 

Similarly, in Figure 8 b), GPS reception circuitry 542 comprises the RF 
processing functions required for implementation of a GPS receiver. These are embodied 
in a series of semiconductor devices constituting a chipset for implementation of a GPS 
receiver As these devices constitute externally defined components that are integrated in 
the present invention, only those components that interface with the host system are 
numbered. 

Yet another embodiment is shown in figures 9 to 15. The term 
"Automotive Telemetry" refers to the conveyance of operational data from a mobile 
vehicle to a regulatory or maintenance authority as well as to other, neighboring mobile 
vehicles. The data transmitted are acquired directly from analog and digital sensors, the 
in-vehicle data bus, ECU and from a GPS receiver. The data are conveyed via a wireless 
packet-oriented data links provided by terrestrial RF packet networks, spread spectrum 
and satellite. 

An Automotive Telemetry System according to the present invention may 
be configured to enable interested parties (regulatory agencies, OEM's, dealers) to obtain 
critical automotive performance information in a wireless manner. It is believed that a 
system according to the present invention may also be configured to enable: 
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- reliable, substantially error-free data communications between the on-board 
CPU and persistent data storage; 

- high-level services in the form of API's (Application Programmer Interfaces) 
for real-time alarm monitoring, trending and back-office decision-support 
systems. IT developers responsible for maintenance, performance monitoring and 
automotive engineering systems can invoke high-level services that make the 
CAN-bus, or any sensors and actuators, appear as though they are directly 
connected to the fixed-location host system. 

- flexible communications architecture enabling many-to-many, simultaneous, 
multiple virtual connections between on-board CPU's and fixed-location host 
systems. This means that both the on-board CPU and the ground-based 
workstation can maintain client-server relationships with several peers at the same 
time. 

on-board filtering intelligence and remote configuration capability. The on-board 
CPU should have the ability to restrict real-time transmission of diagnostic data 
according to threshold levels that can be dynamically changed from a fixed- 
location host. In addition, the host should also be able to remotely configure the 
frequency and duration of telemetry reports as well as logging to nonvolatile ram 
(NOVRAM); 

- minimal use of wireless bandwidth. There is an inherent economic cost 
associated with the deployment of infrastructures supporting wireless data links, 
regardless of the method used to recover this cost. Therefore both the application 
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and the communication software should, where possible, minimize the use of 
these links through such methods as exception-driven reporting and data 
compression. 

An exemplified system according to the present invention has three components: 

- Universal On-Board Diagnostic (UOBD) Server (m-vehicle telemetry 
computer) 

- Communications Protocol Stack 

- Application Programmer Interface (API) 

A hardware instantiation of the m-vehicle UOBD Server has been built 
based on an embedded 80386 CPU and a hard real-time multitasking kernel. The current 
model incorporates the following features: 

- 512KB flash memory (192 KB for data logging) 

- 512 SRAM 

- 8 A/D channels for analog sensor inputs 

- 8 digital channels for discrete inputs (each channel configurable as an output) 

- CAN-interface 

- RS-485 serial ports for interface to J-l 708 bus (heavy trucks and buses) 

- 2 RS-232 ports for PPP and/or IrDA (InfraRed) connections with external 
computing devices. 

- GPS receiver with NMEA-compliant data link to the CPU 

- RF packet radio network interface (Mobitex or ARDIS) 
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- Spread spectrum data link (2.4 GHz ISM band, frequency hopping CMSA/CA 
protocol) 

Real-Time Executive 

The operating kernel adopted for the UOBD is RTEMS (Real-time 
executive for multi-processor systems). However, the entire body of software embedded 
in the UOBD (with the exception of the real-time kernel itself and bootstrapping code) is 
capable of running in alternative operating environments. This is achieved through the 
definition of an abstract operating system in terms of an object-oriented abstract base 
class, with specific instantiations for whatever operating environments are required. 

In particular, a Windows NT instantiation of the operating environment 
has been developed for emulation and testing of the embedded system. 

Communications Sub-System 

The communications sub-system is a protocol stack which supports any 
combination of terrestrial RJF packet network, satcom packet networks and short-range 
spread spectrum data links. As shown in Figure 9, the software architecture treats each 
wireless data link as part of a sub-network according to the Internet paradigm. 

The Internet standards are implemented within the protocol stack so that, 
if required, the UOBD Server can become addressable on the Internet. Internet 
accessibility to the UOBD Server is an option which facilitates remote diagnostics by a 
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variety of authorized clients. The protocol capabilities of the device include both PPP 
and IrDA (InfraRed) which provide connectivity to other devices in the vehicle such as 
palm-tops or notebook computers. 

The architecture of the communications sub-system is designed to provide 
an infrastructure for "seamless" peer-to-peer communications between the vehicle and a 
fixed-location host system or another vehicle. 

The following sections describe the various layers of the protocol stack in 

more detail. 

Session Layer: Automotive Telemetry Protocol 

The Automotive Telemetry Protocol (ATP) provides a simple and effective 
bi-directional request-response mechanism. From the vehicle. ATP allows the diagnostic 
monitor embedded in the UOBD Server to report fault conditions to a host system 
application. In the reverse direction, diagnostic inquiries and parameter configurations can 
be issued from the host. The ATP message syntax is similar to that of SNMP and contains 
streamed versions of Object Identifiers (OID's) as ameans of specifying the performance or 
operational parameter to which the message pertains. 

Figure 1 0 illustrates this mechanism with the request initiated from a fixed 
location host. However, the implementation of the ATP supports both client and server 
functionality in either the host or the UOBD Server. As such, the UOBD Server may provide 
simultaneous OBD services to more than one (authorized) OBD "client" 

Sub-net and DataLink Layers: Hybrid RF 
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Short-range spread spectrum data links provide a powerful complement to RF 
packet networks for vehicle-to- vehicle telemetry and a potentially low-cost mechanism for 
OBD-III compliance monitoring. The UOBD incorporates both technologies with the 
intelligence to switch between them on a "least-cost" basis. In order to preserve the IP 
addressing mechanism allowing for a unique IP address at the interface between the UOBD 
Se er's IP module and the drivers for its wireless data links, the present system has 
implemented the concept of 

- an Hybrid Network, which is an abstraction that combines multiple physical data 
links. This is illustrated in Figure 1 1 . 

Any node on a Hybrid Network is either an in-vehicle UOBD Server or a 
Hybrid Network Gateway (HNG) . This is a ground-based EP gateway to the Hybrid Network 
and is functionally symmetrical to the UOBD Server. It has an IP module bound to a network 
interface for the Hybrid Network. This network interface has a unique IP address. 

The current HNG resides on a dedicated Windows NT workstation and 
effectively provides an IP-level gateway between the Hybrid Network and the rest of the 
Internet or corporate Intranet. 

The complete protocol stack for a hybrid network node is illustrated in Figure 
9 At the lowest level of this stack are data link drivers for RF packet networks. A 
combination of such data links is subsumed by a single abstract Hybrid Network interface, 
which is responsible for switching outbound transmissions over the least-cost data link in a 
manner that is transparent to the IP. The "cost" of using any given wireless data link is 
expressed as a measure of "impedance", which is established in terms of the monetary cost 
of transmission and of the availability of service. 
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Figure 12 illustrates the mechanism implemented for switching of mobile- 
originated frames over the least-cost wireless data link. Note that this describes the protocol 
behavior only at the data link layer of the stack. The behavior of the stack at other layers is 
described hereinbelow. 

5 In part (a) of Figure 12, the UOBDCPU sends a frame over the serial link to 

the primary RF radio modem (spread spectrum), which in turn successfully sends it over the 
airlink to a base radio modem (spread spectrum access point). From there, the payload is sent 
to the Hybrid Network Gateway from where it can be routed over a network backbone 
(possibly the Internet) to a host system. 

10 Part (b) of Figure 1 2 shows the instance where a mobile-originated frame fails 

to traverse the airlink. In this instance, a failure notification is received, either from the radio 
modem, or from a timer expiry within the CPU. The failure notification is propagated back 
up the protocol stack to the process which was responsible for the message contained in the 
frame (e.g. the ATP client or server process), which can then choose to reschedule the 

15 transmission. The failure notification also causes the impedance level for the destination 
address to be raised to a maximum level. The retry is therefore earned out over the alternate 
RF data link. The impedance will be lowered whenever a notification is received that the 
mobile has returned within M RP range" of the base. 

Network Layer: In-Vehicle Routing and IP Header Compression 

20 The IP implementation is intended to enable the UOBD Server to act as a 

gateway from the wireless HybridNetwork to a subnet of computing devices used within the 
vehicle. The data link used for any of the devices is PPP (point-to-point protocol) over an 
RS-232 serial connection. This is designed to support a palm-top or notebook computer 
using PPP with a direct serial link to obtain a temporary CP address. 
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In many cases, the Automotive Telemetry System does not encompass more 
than one host site (client). The mobile UOBD Servers do not therefore need to distinguish 
between remote addresses. Furthermore, the Hybrid Network Gateway has address tables for 
resolving all IP addresses to unique physical addresses, associated with each of the RF data 
links, for each UOBD. Therefore, mobile-terminated datagrams do not require an explicit 
destination address in transmission. Similarly, mobile-originated datagrams do not require 
an explicit source address in transmission. In these cases, the EP headers can be compressed 
from 20 to 3 bytes, without loss of information. The overhead of 3 bytes is necessary to 
provide a sequence number for the datagram, an identifier for the transport protocol to be 
used and the m-vehicle subnet address of the destination. Regardless of the protocol, this 
amount of overhead would be required in any event. 

The IP implementation supports varying levels of compression 
simultaneously. Telemetry traffic from a "well-known" client is subject to full compression 
as described above, whereas "external" Internet traffic must preserve more header 
information. 

Transport Layer: UDP and ICMP 

There are two basic types of transport protocol: "stream-oriented" and 
"datagram". The corresponding specifications commonly used in conjunction with the 
Internet are called, respectively, TCP (Transport Control Protocol) and UDP (User Datagram 
Protocol) 

When the quantities of data transmitted are very small, relative to the 
maximum size of individual packets allowed over the wireless data links, the transport 
mechanism used is UDP. Typically, this is applied in a « request/response » mechanism one 
of the following three (3) scenarios : 
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-Host « requests » data for a specific parameter - UOBD Server « responds » 

- UOBD Server reports alarm value for a specific parameter - Host confirms alarm 
received 

- Host « commands » UOBD Server to set new configuration value - UOBD Server 
confirms setting. 

The transport-level protocols included in the stack are UDP (User Datagram Protocol) 
and ICMP (Internet Control and Message Protocol). UDP supports the Automotive 
Telemetry Protocol in a manner identical to its use in other request/response protocols such 
an SNMP. 

In contrast to UDP. TCP/IP provides what is commonly referred to as a 
« reliable, stream-oriented, virtual circuit ». Variable quantities of data can be pushed into 
the circuit at one end. and will be delivered at the other end in the same sequence that they 
were submitted. If errors occur, or individual packets traversing the actual physical networks 
are lost, the TCP/IP protocol stack is responsible for re-transmission. However, this is not 
manifest to the application software using the circuit. At each end of the circuit (called a 
« socket ») . all that is understood is two steady « streams » of octets (bytes) : one for 
reception and one for transmission. 

The successful operation of TCP/IP requires significant « overhead ». i.e. 
octets which are not part of the deliverable « pay load » but are used for addressing, routing 
and retransmission control. Therefore, in a network environment where transmission of each 
packet is relatively expensive, such as RF TCP/IP should be used frugally. 

ICMP is used as an error reporting mechanism, specifically for the case where 
the destination for an EP datagram cannot be reached. This mechanism is used in conjunction 
with a switching mechanism for directing over the least-cost wireless data link. 
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The use of ICMP is illustrated in Figure 1 3 . The fixed location host sends an 
ATP message using UDP to the mobile. (It is irrelevant whether the ATP message is a 
request or a response. UDP is indifferent). The message is transported in an Internet 
datagram which must transit the Hybrid Network Gateway. The HNG attempts to route the 
datagram to the UOBD using the primary RF data link. This attempt fails because the UOBD 
is not currently reachable via the primary RF data link. 

The HNG is not responsible for attempting a retry. Instead, it generates, on 
reception of the failure notification from the RF data link, an ICMP "destination 
unreachable" message which is sent to the source address of the original IP datagram. The 
ATP process (either client or server, depending on whether the ATP message was a request 
or a response) handing this message can reschedule a retransmission at a later time. In the 
meantime, the HNG will have changed the impedance level of the primary RF data link for 
the destination address in question. When the datagram transmission is retried, the HNG will 
route it through the lower impedance data link, i . e. the alternate RF data link. The impedance 
of the primary RF data link will return to its lower level when a registration packet is 
received from the mobile indicating that it is reachable, i.e. it is within "RF range". 

Figure 9 also shows the TCP and IGMP protocols at the transport level. These 
protocols are not incorporated in the current version of the UOBD Server but they may have 
future roles in, respectively, "batch" data acquisition and multicast messaging to fleet groups 

API 

The API. as described in the system objectives, provides a platform on which 
application programmers can develop database systems and user interfaces. The API resides 
above the Automotive Telemetry Protocol at the "Presentation" layer of the stack. ATP is 
derived from SNMP. and therefore the API resembles an interface to SNMP. It consists of 
three types of objects which must be allocated and which methods must be invoked to 
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execute the interface. The following provides brief definitions for these objects and a 
conceptual outline of their use. The precise class definitions, function prototypes, 
initialization sequences and so on. are provided in a separate programmer's manual. 

Diagnostic information Base (DIB) 

These objects are similar to the notion of M1B (Management Information 
Base) used in SNMP. Each one corresponds to a specific data source from the vehicle: e.g. 
engine temperature, oil pressure, fuel level, etc. They have a unique OLD (object identifier) 
and a cache variable for stonng for the most recent value received from a remote vehicle. A 
DIB must be allocated for each data source which the application intends to monitor from 
any given vehicle. Only one DIB is required for a given data source, regardless of the 
number of vehicles being monitored. In other words, DIB's are not needed for each vehicle 
but only for each unique type of data. 

All the DIB's are held in a container belonging to the ATP (see below) When 
a DIB is allocated, the user must add it to the ATP container by invoking a method of the 
ATP. 

ATP (Automotive Telemetry Protocol) 

The ATP is the object that encapsulates the UDP portion of the 
communications protocol stack. A method of the ATP is used to allocate a "listener", which 
is an ATP Server object that handles requests from unknown remote clients. If a UDP 
message had been received from a mobile client for which no ATPClient object (see below) 
has been allocated, the ATPServer allocates a new ATPClient and registers it with the DIB's 

ATPClient 
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An ATPClient should be allocated for each remote vehicle being monitored. 
The ATPClient needs to be "registered" with each DIB in the container belonging to the 
ATP 

Sending requests to a mobile is accomplished in two (2) steps. First, the user 
needs to invoke the appropriate ATPClient methods which will specify the OED, the message 
type (i.e. what type of command is being issued to the remote) and any data values which 
should be appended to the message (e.g. new thresholds for alarms). In the second step, the 
transmit method of the ATPClient is invoked. 

Reception of messages from a mobile, whether requests or responses, is 
handled within the ATP. The user can provide a "hook" for each ATPClient to process the 
pay load data of both requests and responses. This is registered with the ATPClient in the 
form of a function pointer. For processing of requests, the user-supplied function should 
indicate to the caller whether the data was correctly processed. For example, if the request 
received is to log an alarm to persistent storage and there is an error, a Boolean return code 
should indicate FALSE. As a result, the response message to the mobile will indicate failure 
and appropriate action can be taken at the mobile end (i.e. rescheduling the transmission). 

Design and Development Practices 

Object Design 

All software implementation is based on the obj ect-onented design principles 
of inheritance and encapsulation. This means that every module (class definition) of the 
software is derived from an abstract base class (with the exception of the abstract base 
classes themselves). This section describes the class hierarchies at the Operating System 
level and the data link layer of the protocol stack. 
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Operating Kernel 

The operating system level is defined as an abstract set of services, to which 
user interfaces are standardized in order to facilitate rapid porting of the code to different 
operating environments. This is illustrated in Figure 1 1. 

Figure 14 also shows various instantiations of the multi-tasking kernel, 
including a "device emulation" version in Windows NT. 

Data Link Layer 

All the data links in the embedded system, whether airlmks to RF packet 
networks or internal bus data links (CAN, J-1708) share common logic which is 
implemented in a generic data link object. The entire behavior which is unique to any 
particular data link protocol is encapsulated in class derivations of an abstract base class 
called a link identity. 

This architecture, illustrated in Figure 14, is intended not only to minimize 
the code space required in the embedded system, but also to facilitate rapid integration of 
new RF data link protocols, particularly as they become available in the form of newly 
deployed infrastructures. 

While this invention has been described with reference to illustrative 
embodiments, this description is not intended to be construed in a limiting sense. Various 
modifications of the illustrative embodiments as well as other embodiments will be apparent 
to a person of skill in the art upon reference to this description. It is therefore contemplated 
that the appended claims will cover any such modifications or embodiments. 
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What is claimed is: 

1 A method of exchanging data between a mobile node and an access point on 

a communication network, comprising the steps of: 

a) providing at least two data links between the mobile node and the access 
point: 

b) measuring impedance on each data link, and 

c) transmitting said data across the data link having the lowest impedance. 

2. A method as defined in claim 1, wherein a first of said data links is 
established on a spread spectrum band. 

3. A method as defined in claim 1 . wherein said mobile node and said access 
point are IEEE 802.1 1 compliant. 

4. A method as defined in claim 1 . wherein one of said data links is a satellite 
RF packet network. 

5. A method as defined in claim 1 , wherein one of said data links is a terrestrial 
RF packet network. 

6 A communications system, comprising 

a mobile node, 

a fixed communications network having an access point, 
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a pair of alternative data links, each of which joins said mobile node with said 
access point, and 

a switching unit for switching between said alternative data links to exchange 
data between said mobile node and said access point. 

5 7 A system as defined in claim 6. wherein said mobile node is Internet 

addressable. 

8. A system as defined in claim 6, further comprising a measuring module for 

measuring impedance on each of said data links, said switching unit being operable to select 
the data link having the least impedance. 

10 9 A system as defined in claim 6. wherein both said mobile node and said 

access point are EEEE 802. 1 1 compliant. 

10. A system as defined in claim 6, wherein said mobile node is one of a plurality 
of mobile nodes on a communications network. 

11. A system as defined in claim 10, wherein each of said mobile nodes is on a 
15 vehicle. 

1 2. A system as defined in claim 6, wherein said fixed communications network 
includes a plurality of access points, wherein said data links join each mobile node with at 
least one access point. 

13 A system as defined in claim 12. wherein some of said access points are 

20 located adjacent a roadway. 
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14 A system as defined in claim 10 wherein at least some of said mobile nodes 

are Internet addressable. 

15. A system as defined in claim 10. wherein at least some of said mobile nodes 

are IPv6 addressable. 

5 16 A communications network for exchanging data between a plurality of 

vehicles, compnsing a computing unit onboard a corresponding vehicle, each computing unit 
operable in a first phase to broadcast enquiry messages in a region surrounding said vehicle, 
a second phase to receive reply messages from other vehicles in said region, a third phase to 
exchange status messages with selected ones of said other vehicles. 

10 17 A network as defined in claim 1 6. wherein each computing unit includes an 

IEEE 802.il node. 

1 8. A network as defined in claim 16. wherein each computing unit exchanges 

data using an SNMP-derived protocol. 

19 A network as defined in claim 16. wherein each node is Internet addressable. 

1 5 20. A vehicle comprising an onboard computing unit which is operable in a first 

phase to broadcast neighbour solicitation messages in a region surrounding said vehicle, a 
secondphaseto receive neighbour response messages from computing units of other vehicles 
in said region, and a third phase to exchange status messages with computing units of 
selected other vehicles. 

20 21. A vehicle as defined in claim 20. which is operable in a fourth phase to 

exchange data with a remote site. 
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22. A vehicle as defined in claim 2 1 . wherein the remote site is reached through 
non-mobile network gateway. 

23. A vehicle as defined in claim 20 wherein said computing unit includes an 
IEEE 802.1 1 node. 

5 24 A vehicle as defined in claim 20. wherein said computing unit is capable of 

exchanging data using an SNMP protocol. 

25. A hybrid communications system, comprising a wired network pom on and 
a wireless network portion, each having a network connection node, at least two data link 
means between the network connection nodes, and a switch means for enabling either of the 

1 0 data links for data exchange between said connection nodes. 

26. A system as defined in claim 25, further comprising measurement means for 
measuring impedance on said data links, said switch means being responsive to said 
measurement means for enabling the data link having a lower impedance. 

27. A vehicle communications system having a controller, a data pathway joining 
1 5 said controller with a plurality of vehicle components and means for establishing a data link 

with other vehicles within a given region surrounding said vehicle in order to exchange data 
therewith. 

28 A system as defined in claim 27. wherein said data link is operable in A 

spread spectrum band. 

20 29. An operational event -reporting system for use by a plurality of neighboring 

vehicles to support IVHS composing a plurality of communication units, each onboard a 
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corresponding vehicle to collect operational data from selected components thereof and to 
exchange data with the communication units of one or more of the neighboring vehicles. 

30. A system as defined in claim 29. wherein the communication units broadcast 
messages on a spread spectrum band. 

31. A method of exchanging data between a vehicle and at least one remote site, 
comprising the step of providing the vehicle with a transmitter and receiver capable of 
transmitting and receiving messages under an SNMP protocol. 

32. A method as defined in claim 3 1 . wherein the at least one data exchange site 
includes a neighboring vehicle. 

33. A method as defined in claim 32. further comprising the steps of: 

- exchanging discovery signals with neighbonng vehicles; and 

- exchanging status data with selected ones of the neighbouring vehicles. 

34. A system for transferring data between a vehicle and a data exchange site, 
comprising a pair of data Link means, wherein at least one of said data link means has a 
varying signal impedance level and switch means for switching between said data link means 
so that said data is transferred on the data link means having the least impedance. 



35. A system as defined in claim 34. 

operable in a spread spectrum band. 

36 



wherein a first of said data link means is 



An extension of the hybrid RF packet network comprising: 
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(i) an interface to an IEEE 802. 1 1 data link integrated in the Hybrid Network 
Radio; 

(li) an IEEE 802. 1 1 Access Point acting as an IPv6 router and a foreign mobility 
agent for mobile nodes implementing Mobile IP; 

5 (iii) an interface to a non-wireless subnetwork from which the Hybrid Network 

Gateway can route mobile-terminated traffic through an IEEE 802. 1 1 Access Point; 
and 

(iv) a cluster intelligence module, based on the establishment of ad-hoc networks 
between a vehicle and its IEEE 802.1 1 neighbors. 

10 37. The system according to claim 36, wherein mobile nodes that are ATP- 

enabled can exchange Internet traffic with regulatory agencies over license-free wireless data 
links (IEEE 802. 1 1) whenever connections are established with Mobile IP-enabled Access 
Points. 

38 The system according to claim 37, wherein the cluster intelligence module is 
1 5 operable using ATP from vehicular node to acquire information about the automotive 

behavior of any of its discovered neighbors. 

39 A method of exchanging data between a mobile node and an access point on 
a communications network, comprising: 

a) a step for providing at least two wireless data links between the mobile 
20 node and the access point; 

b) a step for measuring impedance on each data link, and 
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c) a step for transmitting said data across the data link having the lowest 
impedance. 

40. A method as defined in claim 39, wherein a first of said data links is 
established on a spread spectrum band. 

41 . A method as defined in claim 39, wherein the mobile node and the access 
point are IEEE 802.1 1 compliant. 

42. A method as defined in claim 39. wherein one of said data links is a satellite 
RF packet network. 

43 A method as defined in claim 39, wherein one of said data links is a terrestrial 

RF packet network. 

44. A method of exchanging data between a motor vehicle and a remote station, 
comprising: 

a) a step for providing at least two data links between the vehicle and the 
station; 

b) a step for measuring impedance on each data link; and 

c) a step for transmitting said data across the data link having the lowest 
impedance. 

45. An inter-vehicle communications network, comprising at least two motor 
vehicles, each having an on-board control system, the system including monitoring portion 
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and a spread spectrum radio portion and which is operable to exchange useful vehicle 
operational data with the control system of the other vehicle. 

46. A network as defined in claim 45 wherein each monitoring portion is capable 

of registering a vehicular event. 

47 A network as defined in claim 45, wherein each control system is operable 

with other vehicular override systems to override a vehicle function according to a vehicular 
event. 

48. A network as defined in claim 45. wherein each control system includes a 
memory portion for storing vehicle operational data of the other vehicle. 

49. A network as defined in claim 45. further comprising at least one remote 
station which includes a spread spectrum radio portion to be capable of exchanging data 
with either of said vehicles. 

50 A network as defined in claim 49, wherein the remote station is an internet 

access point. 

51. A network as defined in claim 50. wherein the vehicles are operable to 
exchange data using an SNMP-derived protocol. 

52. A network as defined in claim 49. wherein the remote station is located along 
a road way on which the vehicles are traveling. 

53. A network as defined in claim 52. wherein a plurality of remote stations are 
located along said roadway . 
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54. A network as defined in claim 45, wherein each vehicle is capable of 
monitoring vehicular events in its own region. 

55. A motor vehicle comprising an onboard general purpose computer and a 
spread spectrum radio, the computer operable to monitor a number of predetermined 
operating char actens tics ofthe vehicle, the spread spectrum radio operable to establish a data 
link with a radio in at least one other neighbouring vehicle, wherein the computer is capable 
of identifying at least one vehicular event from data received on the data link. 

56. A computer program product for operating a programmable computer system 
on board a motor vehicle, wherein the system includes a spread spectrum radio, comprising 
a computer readable medium including the computer executable steps of: 

- instructing the radio to issue a signal to a region surrounding the motor vehicle; 

- monitoring the radio for reply signals from other vehicles in the region; and when 
a reply signal is received from another vehicle, 

- establishing a data link with the other vehicle; and 

- exchanging operational data with the other vehicle over the data link. 

57. A mobile automotive telemetry system for installation on-board a vehicle, 

comprising: 

(i) diagnostic means for monitoring operational functions of the vehicle and 
generating operational information; 

(ii) memory for storing the generated operational information; and 
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(iii) a server, in communication with the diagnostic means and the memory, the 
server comprising: 

(a) means to receive a request from a remote client for the generated 
operational information; 

(b) means to retrieve the generated operational information from the memory 
means; and 

(c) means to transmit the generated operational information to the remote 
client. 

58. The system according to claim 57, wherein the means to receive and the 
means to transmit are wireless communication means. 

59. The system according to claim 58, wherein the wireless communication 
means is an infrared communication means. 

60. The system according to claim 57, further comprising a means to transmit 
generated operational information to a remote client, in absence of a request from the client, 
when the generated operational information satisfies predetermined criteria. 

61. The system according to claim 57, further comprising an Internet access 
means. 

62 The system according to claim 61, wherein the Internet access means is 

compliant with IP V6 internet protocol and allows the server to act as a mobility agent. 

63. The system according to claim 57, further comprising means to interface to 

a global positioning system (GPS) receiver. 
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